home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000823_dsr@hplb.hpl.hp.com _Wed Apr 7 13:06:52 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  7KB
  1. Return-Path: <dsr@hplb.hpl.hp.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA28866; Wed, 7 Apr 93 13:06:52 MET DST
  4. Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA18865; Wed, 7 Apr 1993 13:25:55 +0200
  6. Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 7 Apr 93 12:19:52 +0100
  7. Received: by manuel.hpl.hp.com
  8.     (16.6/15.6+ISC) id AA25551; Wed, 7 Apr 93 12:26:43 +0100
  9. From: Dave_Raggett <dsr@hplb.hpl.hp.com>
  10. Message-Id: <9304071126.AA25551@manuel.hpl.hp.com>
  11. Subject: Re Improvements on HTML
  12. To: www-talk@nxoc01.cern.ch
  13. Date: Wed, 7 Apr 93 12:26:40 BST
  14. Cc: timbl@www3.cern.ch
  15. Mailer: Elm [revision: 66.36.1.1]
  16.  
  17. In <9304061648.AA02068@www3.cern.ch> Tim says
  18.  
  19. > There have been a lot of improvements proposed for HTML.
  20.  
  21. >         - Various forms of includion of graphics
  22. >         - Tables
  23. >         - Forms
  24.  
  25. > I think we should get some concrete proposals for an HTML2 out
  26. > onto this list.  This would bring us closer to a DTD for the
  27. > new thing, which would allow everyone to go out and
  28. > implement it.
  29.  
  30. Glad to hear you say it!
  31.  
  32. > The new format should of course be a superset of HTML.  The first
  33. > thing it should include is indefinite nesting of constructs
  34. > which is not allowed in HTML.
  35.  
  36. Some guidelines would be useful here, e.g. can you nest OL or UL in the
  37. DT glossary text in a DL list, or what about OL within UL within a DL list? 
  38. What level of nesting should browsers aim to show effectively?
  39.  
  40. For formal presentation as an elective Internet standard we should aim to
  41. be as precise as possible, e.g. via accurate DTD's and a range of examples.
  42. I there enclose a DTD fragment with my proposal for forms.
  43.  
  44. > To kick off the discussion, I propose for the forms part the
  45. > following
  46.  
  47. > FIELDS
  48. > ======
  49. > <FIELD NAME="f1" FIELDTYPE=TEXT MAXLEN=40>     </FIELD>
  50.  
  51. Tim, er did you receive my message with a detailed suggestion for forms?
  52.  
  53. My practical experience with building hypertext/forms based interfaces
  54. for sales staff etc. has shown the value of:
  55.  
  56.     o   to be able to freely embed fields in other
  57.         textural or graphical backgrounds
  58.  
  59.     o   the need for fields with constrained types
  60.         e.g. dates, booleans, integer ranges, free text, ...
  61.  
  62.     o   the need to initialise fields with default values
  63.  
  64.     o   the ability to highlight fields as being in error
  65.  
  66.     o   the ability to disable the field to prevent further change
  67.  
  68.     o   the need for one-from-many AND many-from-many menus
  69.  
  70.     o   giving authors control over the realisation of such menus
  71.         e.g. radio buttons, drop down, and permanently visible lists
  72.  
  73. Fields showing derived values, (e.g. a total figure in an expenses claim),
  74. and arbitrary constraints between different fields can be handled by the
  75. server. In this way you avoid can the need for a scripting language.
  76.  
  77. If the user sets a field to an incorrect value, the ability to highlight
  78. the field makes it practical to draw the user's attention to that field
  79. with the implication that its value should be changed. An accompanying
  80. error message can be given as part of the surrounding text.
  81.  
  82. Similarly, it is often the case that given certain settings of fields, that
  83. other fields cannot be changed. To make this obvious you should change the
  84. appearence of these fields. In my browser, I show fields with a darker colour
  85. when they accept input and the lighter window background colour when they are
  86. read-only. Clicking the mouse over a read-only field has no effect.
  87.  
  88. As an author I want control over how a selection menu appears. When there are
  89. few choices, radio buttons or lists work well. When there are lots of
  90. selection fields it is strongly desirable to be able to use drop-down
  91. selections, which appear in the body of the form as a button and a box
  92. showing the currently selected value(s) for that field. Clicking on the
  93. button causes the list of possible choices to appear, with the current
  94. selection highlighted in some way.
  95.  
  96. Essentially we need two tags, one for input fields and one for selections.
  97. These should be able to be placed freely with other HTML tags, so that you
  98. could embed fields in a preformatted text if you need tight control over
  99. the appearence. You could also put input and (dropdown) selection fields in
  100. glossary lists.
  101.  
  102.  
  103. Input Fields:
  104. ============
  105.  
  106. These fields have the following attributes:
  107.  
  108.     o   field name - used to identify the field's value to the server
  109.  
  110.     o   field type - boolean, text, date, uri, integer, float
  111.  
  112.     o   field width (optional) giving maximum length of field value
  113.  
  114.     o   field status (optional) ok (the default), in error, read-only
  115.  
  116.     o   initial value (optional)
  117.  
  118.  
  119. Selection Fields:
  120. ================
  121.  
  122. These fields have the following attributes:
  123.  
  124.     o   field name - used to identify the field's value to the server
  125.  
  126.     o   field type - one-from-many or many-from-many
  127.  
  128.     o   field appearence (optional) radio, list, drop-down
  129.  
  130.     o   field status (optional) ok (the default), in error, read-only
  131.  
  132. The field appearence is a hint to the browser of how the author intends the
  133. field to be displayed. For a drop-down field it would also be desirable to
  134. be able to suggest the maximum size for displaying current selections,
  135. particularly with many-from-many fields.
  136.  
  137. The set of possible choices can be specified as Tim points out with the
  138. <LI> tag without the need for a new tag.
  139.  
  140. Here is my suggested DTD for the <input> and <select> tags. I prefer
  141. these names as they seem more verb-like and appropriate than <field>
  142. and <radio>.
  143.  
  144. <!-- INPUT tag
  145.  
  146.     o   The field name and type are required.
  147.  
  148.     o   The width, status and value attributes are optional.
  149.  
  150.     o   Boolean fields have values "yes" or "no"
  151.  
  152.     o   Date fields have values matching:
  153.  
  154.             "19th January 1992"
  155.             "19 Jan 92"
  156.             "19 Jan 92"
  157.             "19/1/92"   with '/' or '-' as separators
  158.             "1/19/92"
  159.  
  160.     o   URL fields have values corresponding to existing standards
  161.         for universal resource locators
  162.  
  163.     o   values should be enclosed on "quotes"
  164. -->
  165.  
  166. <!ELEMENT INPUT - O EMPTY>
  167.  
  168. <!ATTLIST INPUT
  169.     name ID #REQUIRED
  170.     type (boolean|text|date|url|integer|float) #REQUIRED
  171.     width NUMBER "20"
  172.     status (ok|error|frozen) "ok"
  173.     value CDATA ""
  174. >
  175.  
  176. <!-- SELECT tag
  177.  
  178.     o   The field name and type are required.
  179.  
  180.     o   The showas, width, status and value attributes are optional
  181.  
  182.     o   selected values are indicated with the LI tag
  183. -->
  184.  
  185. <!ENTITY SELECT - - (LI)*>
  186.  
  187. <!ATTLIST SELECT
  188.     name ID #REQUIRED
  189.     type (single|multiple) #REQUIRED
  190.     showas (radio|list|dropdown) "radio"
  191.     width NUMBER "20"
  192.     status (ok|error|frozen) "ok"
  193. >
  194.  
  195. <!-- LI tag
  196.  
  197.     When the LI tag appears inside a <SELECT> ... </SELECT>
  198.     the text following the LI tag is treated as a possible choice
  199.     (up to the next LI tag or the terminating end-select tag).
  200.  
  201.     The LI tag is extended to indicate whether this alternatative
  202.     has been selected or not, e.g.
  203.  
  204.         <LI SELECTED> versus <LI>
  205.  
  206.     Strictly speaking I am not sure if this is valid SGML, you should
  207.     probably always give an attribute value as in <li selected=yes>
  208.     but this seems excessive ...
  209. -->    
  210.  
  211. <!ELEMENT LI - O EMPTY>
  212.  
  213. <!ATTLIST LI
  214.     selected (yes|no) "no">
  215.